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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



CS Fallback in the Evolved Packet System (EPS) enables the provisioning of CS-domain services (e.g. voice call, Short 
Message Service (SMS), Location Services (LCS) or supplementary services) by reuse of CS infrastructure when the 
UE is served by E-UTRAN. 

The present document specifies the procedures and the SGs Application Part (SGsAP) messages used on the SGs 
interface between the Mobility Management Entity (MME) in the EPS and the Visitor Location Register (VLR), to 
allow location management coordination and to relay certain messages related to GSM circuit switched services over 
the EPS system. 

The present document also specifies the use of Stream Control Transmission Protocol (SCTP) for the transport of 
SGsAP messages. 

The present document is applicable to the MME in the EPS and to the VLR. The functional split between the MME and 
the VLR is defined in 3GPP TS 23.272 [7]. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 
[2] 3GPP TS 22.101: " Service aspects; Service principles". 

[3] 3GPP TS 23.003: "Numbering, addressing and identification". 

[4] 3GPP TS 23.007: "Restoration procedures". 

[5] 3GPP TS 23.018: "Basic call handhng; Technical realization". 

[5A] 3GPP TS 23.081: "Line identification supplementary services". 

[5B] 3GPP TS 23.082: "Call Forwarding (CF) supplementary services". 

[6] 3GPP TS 23.195: "Provision of User Equipment Specific Behaviour Information (UESBI) to 

network entities". 

[6A] 3GPP TS 23.236: "Intra-domain connection of Radio Access Network (RAN) nodes to multiple 

Core Network (CN) nodes". 

[7] 3GPP TS 23.272: " Circuit Switched Fallback in Evolved Packet System; Stage 2". 

[8] 3GPP TS 24.008: "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3". 

[9] 3GPP TS 24.010: "Supplementary services specification; General aspects". 

[10] 3GPP TS 24.01 1: "Point-to-Point (PP) Short Message Service (SMS) support on mobile radio 

interface". 

[II] 3GPP TS 24.030: "Location Services (LCS); Supplementary service operations; Stage 3". 
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[12] 3GPP TS 24.081: "Line Identification Supplementary Services - Stage 3". 

[13] 3GPP TS 24.082: "Call Forwarding (CF) supplementary services; Stage 3". 

[14] 3GPP TS 24.301: "Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); 

Stage 3". 

[15] 3GPP TS 29.002: "Mobile Application Part (MAP) specification". 

[15A] 3GPP TS 29.01 1: "Signalling interworking for supplementary services". 

[16] 3GPP TS 29.018: "Serving GPRS Support Node (SGSN) - Visitors Location Register (VLR) Gs 

interface layer 3 specification" . 

[17] 3GPP TS 29.272: "MME and SGSN Related Interfaces Based on Diameter Protocol". 

[18] 3GPP TS 32.422: "Telecommunication management; Subscriber and equipment trace; Trace 

control and configuration management (CM)". 

[19] 3GPP TS 36.331: "Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource 

Control (RRC) protocol specification". 

[20] IETF RFC 791 (September 1981): "Internet Protocol". 

[21] IETF RFC 1035 (November 1987): "Domain Names - Implementation and Specification". 

[22] IETF RFC 2460 (December 1998): "Internet Protocol, Version 6 (IPv6) Specification". 

[23] IETF RFC 4960 (September 2007): "Stream Control Transmission Protocol". 

3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] apply. 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
3GPPTR 21.905 [1]. 

LCS Location Services 

MME Mobility Management Entity 

NEAF Non-EPS Alert Flag 

SCTP Stream Control Transmission Protocol 

SGsAP SGs Application Part 

SMS Short Message Service 

4 Description of tine SGs association between a VLR 
and an IVIME 

4.1 General 

CS Fallback function is realized by reusing Gs interface mechanisms as defined in 3GPP TS 29.018 [16] on the 
interface between the MME in the EPS and the VLR. This interface is called SGs interface. 

NOTE: Within this specification, the term VLR refers to MSCA^LR or MSC Server/VLR. 
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The SGs interface connects the databases in the VLR and the MME. The procedures described in the present document 
are used to co-ordinate the location information of UEs that are IMSI attached to both EPS and non-EPS services. The 
SGs interface is also used to convey some circuit switched related procedures via the MME. 

The basis for the interworking between a VLR and an MME is the existence of a SGs association between those entities 
per UE. The SGs association is only applicable to UEs with CS Fallback capability activated. 

The behaviour of the VLR and the MME entities related to the SGs interface are defined by the state of the SGs 
association for a UE. Individual states per SGs association, i.e. per UE with CS Fallback capability activated, are held at 
both the VLR and the MME. 

4.2 SGs association at the VLR 

4.2.1 General 

The states associated to the SGs interface in the VLR are specified in subclause 4.2.2 and the state diagram at the VLR 
is shown in figure 4.2.2.1. The state diagram does not include the message error handling specified in clause 7. 

4.2.2 States at the VLR 

SGs-NULL 

There is no SGs association with an MME for the UE and therefore the VLR considers that the UE is IMSI 
detached for EPS services. In this state no SGsAP-MM-INFORMATION-REQUEST messages are sent to the 
MME. The VLR may initiate paging on the SGs interface if the "Confirmed by Radio Contact" restoration 
indicator in the VLR is set to "false" (see 3GPP TS 23.007 [4]). Any message from the MME is ignored except 
SGsAP-LOCATION-UPDATE-REQUEST message. 

LA-UPDATE-PRESENT 

The VLR has received an SGsAP-LOCATION-UPDATE-REQUEST message from the MME. In this state, the 
VLR may be waiting for the outcome of the Update Location procedure from the HSS, if the IMSI is not known 
in the VLR. For UEs which are CS Fallback capable and are configured to use CS Fallback, the VLR shall send 
SGsAP-P AGING-REQUEST messages only via the SGs interface. 

SGs-ASSOCIATED 

The VLR considers that the UE is attached to both EPS and non-EPS services. For UEs which are CS Fallback 
capable and are configured to use CS Fallback, the VLR sends SGsAP-P AGING-REQUEST messages only via 
the SGs interface. The VLR can perform the MM information procedure. 
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Figure 4.2.2.1 : State diagram at the VLR 



4.3 



SGs association at the IVIIVIE 



4.3.1 General 

The states associated to the SGs interface in the MME are specified in subclause 4.3.2 and MM context variables 
associated to the SGs interface in the MME are specified in subclause 4.3.3. The state diagram at the MME is shown in 
figure 4.3.3.1. The state diagram does not include the message error handling specified in clause 7. 

4.3.2 IVIIVI context variables at the IVIIVIE 

VLR-Reliable: 

Boolean set to "false" when the MME has received a reset indication from the VLR. The MME may request the 
UE, upon reception of the next tracking area update (periodic or combined) procedure, to re-attach to non-EPS 
services if the UE is still IMSI attached to non-EPS services. Alternatively, the MME may, upon reception of a 
periodic or combined tracking area update request from a UE that is still attached for non-EPS services, perform 
immediately the location update for non-EPS services procedure. 

MME-Reset: 

Boolean set to "true" when the MME restarts after a failure. The "MME-Reset" restoration indicator is unique 
within an MME and it applies to all the MM contexts stored in the MME. 

4.3.3 States at the MME 

SGs-NULL 

There is no SGs association with a VLR for the UE and therefore the MME considers that the UE is IMSI 
detached for non-EPS services. In this state the MME accepts SGsAP-P AGING-REQUEST messages to UEs 
only if the "MME-Reset" restoration indicator in the MME is set to "true". 

LA-UPDATE-REQUESTED 
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The MME has sent an SGsAP-LOCATION-UPDATE-REQUEST message to the VLR. In this state the MME 
waits for the outcome of the Update Location for non-EPS services procedure at the VLR before sending the 
response to the UE. In this state the MME accepts SGsAP-PAGING-REQUEST messages. 

SGs- ASSOCIATED 

The MME stores an SGs association for the UE. In this state the MME performs the location update for non-EPS 
services procedure towards the VLR for UEs capable of and configured to use CS Fallback when they are 
moving to a tracking area not in the list of assigned tracking areas. 
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Figure 4.3.3.1 : State diagram at the IVIIVIE 



5 Procedures for SGs 

5.1 Paging for non-EPS services procedure 

5.1 .1 General description 

This procedure is used by the VLR to send an SGsAP-PAGING-REQUEST message to a UE. This procedure applies to 
UEs that are simultaneously attached for EPS services and non-EPS services. 

5.1.2 Procecdures in tine VLR 



5.1.2.1 



General 



The VLR shall handle the timers, queuing and retransmission for sending the SGsAP-PAGING-REQUEST message on 
the SGs interface in the same way that it handles the sending of a PAGING message on the A or lu interface. 



5.1.2.2 



Paging Initiation 



When a VLR has to page an EPS UE, the VLR shall check whether the VLR has a SGs association for that UE. The 
VLR sends SGsAP-PAGING-REQUEST messages to the MME if the state of the SGs association for the UE is SGs- 



£75/ 



3GPP TS 29.1 1 8 version 8.1 .0 Release 8 1 3 ETSI TS 1 29 1 1 8 V8.1 .0 (2009-04) 

ASSOCIATED, LA-UPDATE-PRESENT or if the state of the SGs association is SGs-NULL and the "Confirmed by 
Radio Contact" restoration indicator is set to "false". The sending of the SGsAP-P AGING-REQUEST message does not 
change the state of the SGs association with the MME. 

If the "Confirmed by Radio Contact" restoration indicator is set to "true", the VLR shall include the Location area 
identifier information element into the SGsAP-P AGING-REQUEST message, otherwise (i.e. after a VLR failure), the 
VLR shall not include the Location area identifier information element. When sending the SGsAP-P AGING- 
REQUEST message, the VLR shall start timer Ts5. 

If the state of the SGs association is SGs-NULL and the "Confirmed by Radio Contact" restoration indicator is set to 
"false", the VLR shall also perform a search procedure as specified in 3GPP TS 23.018 [5]. 

In this message, the VLR includes the Service indicator information element which will be used to indicate the type of 
CS service. 

If the CalHng Line Identification of the service (see 3GPP TS 24.081 [12]) is available in the VLR, the VLR may 
include the CLI information element in the SGsAP-P AGING-REQUEST message. The conditions specified in 
3GPPTS 23.081 [5A] and 3GPP TS 29.011 [15A] apply also here. If the paging is due to a NW-initiated Call 
Independent SS procedure as defined in 3GPP TS 24.010 [9], the VLR shall include the SS code as defined in 
3GPP TS 29.002 [15]. If the paging is due to a Mobile Terminated Location Request as defined in 
3GPP TS 24.030 [11], the VLR shall include LCS cHent identity and LCS indicator as defined in 3GPP TS 29.002 [15] 
in the SGsAP-P AGING-REQUEST. 

While domain specific access control of the PS domain is ongoing, the VLR shall be configured to send paging 
messages on both the SGs and the A/Iu interface. The VLR may apply implementation specific rules for sending the 
paging on the A/Iu interface; e.g. paging on the A/Iu interface may be limited to cases when the UE does not respond to 
a first paging on SGs interface. 

5.1.2.3 Paging Response 

The VLR stops the paging procedure on expiry of timer Ts5 or on receipt of a SGsAP-SER VICE-REQUEST message 
from the MME; if the SGsAP-SERVICE-REQUEST message contains the CS service indicator, additionally the No 
Reply timer is started. 

NOTE: The VLR stops the paging procedure on receipt of an SCCP connection establishment containing the 

Initial L3 message from the UE via the A or lu interface, see 3GPP TS 24.008 [8]. If the No Reply timer 
is running, it is stopped. 

5.1.2.4 Paging Failure 

On receipt of an SGs AP-P AGING-REJECT message before the timer Ts5 expires, the VLR stops timer Ts5. If the SGs 
cause information element in the SGsAP-PAGING-REJECT message does not indicate "Mobile terminating CS 
fallback call rejected by the user", the SGs association is moved to the SGs-NULL state and within this state the SGs 
association is marked with the contents of the SGs cause information element. If the SGs cause information element 
indicates "Mobile terminating CS fallback call rejected by the user", the SGs association state shall not be changed. 

When the VLR receives the SGsAP-PAGING-REJECT message with the SGs cause information element indicating 
"Mobile terminating CS fallback call rejected by the user", the VLR shall trigger User Determined User Busy (UDUB) 
as specified in 3GPP TS 24.082 [13]. 

5.1.2.5 UE unreachable 

On receipt of an SGsAP-UE-UNREACHABLE message before the timer Ts5 expires, the VLR stops timer Ts5, the 
paging procedure for that paging request towards the MME is stopped and the VLR applies the equivalent handling as 
for Call Forwarding on Not Reachable, as specified in 3GPP TS 23.082 [5B] and 3GPP TS 29.01 1 [15A]. The state of 
the SGs association at the VLR is not changed. 

When the VLR receives the SGsAP-UE-UNREACHABLE message after receipt of the service request message, 
including the CS call indicator, from the MME, the VLR may trigger Call Forwarding on Not Reachable (CFNRc) as 
specified in 3GPP TS 23.082 [5B] and 3GPP TS 29.01 1 [15A]; the SGs association state shall not be changed. 
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NOTE: If no SCCP connection establishment containing the Initial L3 message from the UE via the A or lu 

interface is received, as described in 3GPP TS 24.008 [8], before the timer Ts5 expires, the VLR applies 
the equivalent handling as for Call Forwarding on Not Reachable, as specified in 3GPP TS 23.082 [5B] 
and 3GPPTS 29.011 [15A]. 

5.1 .3 Procedures in the MME 

The MME accepts SGsAP-PAGING-REQUEST messages in any state of the SGs association apart from SGs-NULL. 
When a MME receives a SGs-P AGING-REQUEST message from a VLR, if the Service indicator information element 
indicates "CS call indicator", the MME shall first check if the UE is known by the MME. The handling of the paging 
request depends on the state of the SGs association and the EMM context variables at the MME: 

a) If the UE is known: 

if the UE is considered to be IMSI attached for EPS and non-EPS services (i.e. the SGs association is not in 
the state SGs-NULL), the MME shall page the UE based on the location information stored in the MME; 

if the UE is marked as IMSI detached for EPS services or IMSI (implicitly or explicitly) detached for non- 
EPS services (i.e. the state of the SGs association is SGs-NULL), the MME shall return an SGsAP-P AGING- 
REJECT message to that VLR indicating in the SGs cause information element the detach circumstance 
("IMSI detached for EPS services", "IMSI detached for non-EPS services" or "IMSI implicitly detached for 
non-EPS services"); or 

if the UE is marked as unreachable, indicated by Paging Proceed Flag set to "false", the MME shall return an 
SGsAP-UE-UNREACHABLE message to that VLR indicating in the SGs cause information element "UE 
unreachable". The state of the SGs association does not change at the MME. 

b) If the UE is not known and the "MME-Reset" restoration indicator at the MME is set to "false", the MME shall 
handle the paging request as follows: 

- the MME shall return an SGsAP-P AGING-REJECT message to that VLR indicating in the SGs cause 
information element "IMSI unknown". 

c) If the UE is not known and the "MME-Reset" restoration indicator at the MME is set to "true", the MME shall 
handle the paging request as follows: 

if the SGsAP-P AGING-REQUEST message includes the Location area identifier information element, the 
MME shall page the UE in all the tracking areas served by the MME that can be mapped to the location area 
indicated in the Location area identifier information element; or 

if the SGsAP-PAGING-REQUEST message does not include the Location area identifier information 
element, the MME may page in all the tracking areas served by the MME, or the tracking areas served by the 
MME and by the VLR. 

If the MME accepts the paging request and no NAS signalling connection exists, and the VLR TMSI is omitted or the 
UE is not known in the MME, the IMSI is used instead of the S-TMSI as a paging address at the radio interface. If 
location information is reliably known by the MME (i.e. MME stores the list of tracking areas), the MME shall page the 
UE in all the tracking areas. If the MME does not have a stored tracking area list for the UE, the MME shall use the 
location information received from the VLR, if any, to page the UE. 

If the MME accepts the paging request and a NAS signalling connection exists, the MME shall send the CS SERVICE 
NOTIFICATION message through the NAS signalling connection, including the CS service related parameters (CLI, 
SS code, LCS indicator and LCS client identity), received from the VLR, and the MME shall also send a SGsAP- 
SERVICE-REQUEST message, including the CS call indicator to the VLR. 

The UE may decide to explicitly reject the CS fallback call in EMM-CONNECTED mode, based on the Caller Line 
Identification and return a Service Request message to the MME, indicating that the user has rejected the call. The 
MME shall send the SGsAP-PAGING-REJECT message to the VLR with the SGs cause information element indicating 
"Mobile terminating CS fallback call rejected by the user". 
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5.2 Location update for non-EPS services procedure 

5.2.1 General description 

The location update for non-EPS services procedure is a general procedure used by CS Fallback capable UEs. This 
procedure allows UEs and the network to perform: 

combined IMSI attach for EPS and non-EPS services; 

IMSI attach for non-EPS services if the UE is already IMSI attached for EPS services; 

normal location update procedure to the VLR if the UE is IMSI attached to both EPS and non-EPS services; or 

allocation of new TMSI to an UE. 

The location update for non-EPS services procedure in the SGs interface is always started as a consequence of a direct 
action from the UE. The combined attach and tracking area update procedures are further specified in 
3GPP TS 23.272 [7] and 3GPP TS 24.301 [14]. 

When a UE is IMSI attached for EPS and non-EPS services, the VLR shall stop any implicit detach timer. Instead the 
MME uses the "Paging Proceed Flag" to determine the likely availability of the UE to the network. Upon reception of 
the periodic Tracking Area Update message the MME does not report to the VLR, and the MME shall not change the 
state of the SGs association. When the UE performs a detach only for EPS services, the EPS detach indication to the 
VLR shall cause the VLR's implicit detach timer to be restarted from its initial value. 

If the MME performs an implicit detach for both EPS and non-EPS services, then the MME shall send to the VLR an 
SGsAP-IMSI-DETACH-INDICATION message with cause "Implicit MME initiated IMSI detach from non-EPS 
service", as further described in subclause 5.6 (the implicit IMSI detach message indicates that the UE is unavailable for 
both EPS and non-EPS services). 

5.2.2 Procedures in tine MME 

5.2.2.1 General 

The location update for non-EPS services procedure is initiated with a combined attach or a combined tracking area 
update procedure. On receipt of an ATTACH REQUEST message or a TRACKING AREA UPDATE message, the 
MME shall handle the EPS related request as specified in 3GPP TS 24.301 [14]. The location update for non-EPS 
services procedure is handled in parallel to the update location procedure to the HSS and is started by the MME when it 
receives the first Insert Subscriber Data message from the HSS. The MME shall wait for the outcome of both location 
update procedures towards the VLR and the HSS before sending the response message to the UE. 

5.2.2.2 Location update initiation 

If timer Ts6-1 is not running, the MME shall start the location update for non-EPS services procedure when it receives 
from the UE: 

an attach request indicating combined EPS/IMSI attach; 

a combined tracking area update request indicating Combined TA/LA updating with IMSI attach; 

a combined tracking area update request indicating that the UE has entered a TAI not in the registered TAI list; 

a combined tracking area update request and the state of the SGs association is SGs-NULL; or 

a combined tracking area update request and the MME serving the UE has changed. 

If timer Ts6-1 is not running, the MME may start the location update for non-EPS services procedure when it receives 
from the UE: 

a combined tracking area update request or a periodic tracking area update , if the MM context variable " VLR- 
Reliable" for the MS is set to "false" (see subclause 5.7.3). 

The MME shall determine the new location area identification as follows: 
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if the MME received an attach request from the UE, or a combined tracking area update request from the UE 
with a GUTI information element which is not mapped from a P-TMSI/RAI, the MME shall set the new 
location area identification to a default location area identification. This default location area identification, 
configured in the MME, may be determined depending on the current tracking area and the current E-UTRAN 
cell global identity where the UE is located; or 

if the MME received a combined tracking area update request from the UE and the GUTI information element is 
mapped from a P-TMSI/RAI, the location area identification is retrieved from the RAI. 

The MME shall derive the VLR name from the location area identification which was determined. In case multiple 
VLRs serve this location area identification, the MME shall use the location area identification and an IMSI hash value 
to retrieve the VLR name. The MME shall include the location area identification in the new location area identifier 
information element in the SGsAP-LOCATION-UPDATE-REQUEST message. 

NOTE: The selection of the VLR in the MME follows the same rule as the selection of the VLR in the SGSN, as 
defined in 3GPP TS 23.236 [6A], and the same IMSI hash values and IMSI hash tables are used by the 
MME and the SGSN. 

In networks supporting the feature "Intra Domain Connection of RAN Nodes to Multiple CN Nodes" as defined in 
3GPP TS 23.236 [6A], the MME shall support load re-distribution of UEs to another VLR than the current one. When 
the MME receives a periodic tracking area update request or a combined tracking area update request, the MME shall 
check whether for this UE there is a SGs association to a VLR for which load re-distribution has been initiated in the 
MME by O&M. If this is the case, the MME derives the new VLR name using the new IMSI hash table configured in 
the MME. The MME shall then send the SGsAP-LOCATION-UPDATE-REQUEST message to the new selected VLR. 

The SGsAP-LOCATION-UPDATE-REQUEST message includes the type of location update performed by the UE in 
the EPS location update type information element. If the UE has performed a combined attach or a combined tracking 
area update indicating Combined TA/LA updating with IMSI attach, the MME indicates "IMSI attach", otherwise the 
MME indicates "Normal location update". 

The MME shall include the TMSI status in the SGsAP-LOCATION-UPDATE-REQUEST message if the UE indicates 
in the ATTACH REQUEST or the TRACKING AREA UPDATE REQUEST message that it has no valid TMSI 
available. The MME shall also include the old location area identifier in the SGsAP-LOCATION-UPDATE-REQUEST 
message if the UE included the old location area identification in the ATTACH REQUEST or TRACKING AREA 
UPDATE REQUEST message. 

If the MME supports the "Provision of UE Specific Behaviour Information to Network Entities" (see 
3GPP TS 23.195 [6]), or the "Automatic Device Detection" (see 3GPP TS 22.101 [2]) or the "Trace for Management 
Based Activation/Deactivation" (see 3GPP TS 32.422 [18]), the MME shall include the IMEISV in the SGsAP- 
LOCATION-UPDATE-REQUEST message. 

When the MME sends the SGsAP-LOCATION-UPDATE-REQUEST, the MME shall start timer Ts6-1. 

If timer Ts6-1 is running and the MME receives from the UE: 

an attach request indicating combined EPS/IMSI attach; or 

- a combined tracking area update with or without IMSI attach. 

Then: 

if the LAI determined by the MME is the same as in the outstanding request, the MME shall not process this 
new request and shall wait for the VLR response to the ongoing procedure; 

if the LAI determined by the MME is different but the VLR name is the same as for previous LAI, any response 
from the VLR to the outstanding request is ignored, the MME shall stop and reset timer Ts6-1 and the MME 
shall start the location update for non-EPS services procedure; or 

if the LAI determined by the MME is different and the VLR name is different as for previous LAI, any response 
from the previously addressed VLR to the outstanding request is ignored, the MME shall stop and reset 
timer Ts6-1, and the MME shall start the location update for non-EPS services procedure. 

When the MME receives from the UE a tracking area update request and the MME serving the UE has changed, the 
MME shall stop and reset timer Ts6-1. 
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5.2.2.3 Location update response 

If the MME receives an SGsAP-LOCATION-UPD ATE- ACCEPT message from the VLR, the MME shall stop 
timer Ts6-1 and: 

- move the state of the SGs association to SGs-ASSOCIATED; 

- set the MM context variable "VLR-Rehable" to "true"; and 

indicate to the UE the acceptance of the VLR to the location update procedure. The message sent to the UE 
includes the Location Area Identity (see 3GPP TS 24.301 [14]). 

The MME shall wait for the outcome of the location update for non-EPS services procedure towards the VLR before 
sending a response to location update procedure to the UE. When the MME receives an SGsAP-LOCATION- 
UPDATE-REJECT message from the VLR, it will map the reject cause received to the appropriate reject cause as 
specified in 3GPP TS 24.301 [14], and report this reject cause to the UE. 

If the VLR included the Mobile identity information element in the SGs AP-LOCATION-UPD ATE- ACCEPT message, 
the MME shall relay the information received to the UE. If the Mobile identity information element contains a new 
TMSI, this will cause the UE to perform a TMSI reallocation procedure. In this case, the MME shall send to the VLR 
the SGsAP-TMSI-REALLOCATION-COMPLETE message when the MME receives the ATTACH COMPLETE or 
the TRACKING AREA UPDATE COMPLETE message from the UE. If the Mobile identity information element 
contains an IMSI, this will cause the UE to deallocate its TMSI. 

5.2.2.4 Location update failure 

If the MME receives an SGsAP-LOCATION-UPDATE-REJECT message from the VLR, the MME shall: 

stop timer Ts6-1; 

move the state of the SGs association to SGs-NULL; and 

indicate to the UE the rejection of the Location Update procedure by the VLR as specified in 
3GPP TS 24.301 [14]. The Reject cause value sent by the VLR shall be forwarded to the UE. 

5.2.2.5 Abnormal cases 

If timer Ts6-1 expires, the MME shall abort the Location Update for non-EPS service procedure and indicate this to the 
UE with the Reject cause value 'MSC temporarily not reachable'. The state of the SGs association to the VLR shall be 
SGs-NULL. 

If the MME receives an SGsAP-LOCATION-UPDATE-ACCEPT message and timer Ts6-1 is not running then: 

if timer Ts8 is running (see subclause 5.4), the message shall be ignored; 

if timer Ts9 is running (see subclause 5.5), the message shall be ignored; or 

if timers Ts8 and Ts9 are not running: 

if the state of the SGs association to the VLR is SGs-ASSOCIATED, the message shall be ignored; or 

if the state of the SGs association to the VLR is different than SGs-ASSOCIATED, the message shall be 
treated as a message incompatible with the protocol state of the MME (see subclause 7.3). 

5.2.3 Procedures in the VLR 
5.2.3.1 General 

When a VLR receives an SGsAP-LOCATION-UPDATE-REQUEST message, the VLR shall check whether the IMSI 
is known. If the IMSI is not known, the VLR shall retrieve the MM context of the UE from the HSS. 

For a VLR supporting the "Provision of UE Specific Behaviour Information to Network Entities" (see 
3GPP TS 23.195 [6]) the following apphes: 
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- the VLR shall store the IMEISV value received in the SGsAP-LOCATION-UPDATE-REQUEST message in 
the MM context for that MS; and 

- if the VLR receives an SGsAP-LOCATION -UPDATE-REQUEST message without IMEISV information 
element, the VLR shall request the IMEISV from the UE at the next lu or A interface connection establishment. 

5.2.3.2 Location update response 

If the location update is accepted by the VLR and, if necessary, by the HSS, the VLR shall: 

- move the SGs association to the SGs-ASSOCIATED state; 

set the "Confirmed by Radio Contact" restoration indicator to "true"; 

- update the SGs association by storing the MME address included in SGsAP-LOCATION-UPDATE-REQUEST 
message; and 

- send an SGsAP-LOCATION-UPDATE-ACCEPT message to the sending MME. This message includes the 
location area identifier received in the New location area identifier information element in the previous SGsAP- 
LOCATION-UPDATE-REQUEST message. 

5.2.3.3 Location update failure 

If the location update is rejected by the VLR, the VLR shall: 

- send an SGsAP-LOCATION-UPDATE-REJECT message to the MME with the appropriate reject cause as 
indicated in 3GPP TS 24.008 [8]; and 

move the SGs association to SGs-NULL. 

5.2.3.4 TMSI reallocation procedure 

If the VLR decides to allocate a new TMSI to the UE, the VLR shall include the new TMSI in the SGsAP-LOCATION- 
UPDATE-ACCEPT message. After sending the SGsAP-LOCATION-UPDATE-ACCEPT message with a new TMSI 
the VLR shall start timer Ts6-2. If the VLR decides to deallocate the TMSI of the UE, the VLR shall include the IMSI 
of the UE in the SGsAP-LOCATION-UPDATE-ACCEPT message. 

Upon receipt of the SGsAP-TMSI-REALLOCATION-COMPLETE message, the VLR shall stop the timer Ts6-2 and 
consider the new TMSI as valid. 

If the IMSI was sent to the UE, the VLR considers the old TMSI as deleted. 

If no SGsAP-TMSI-REALLOCATION-COMPLETE message is received by the VLR before the timer Ts6-2 expires, 
the VLR aborts the TMSI reallocation procedure. The outcome of the TMSI reallocation procedure does not change the 
state of the SGs association. The VLR uses the IMSI or the new TMSI for paging. 

5.2.3.5 Abnormal cases 

The following abnormal cases can be identified: 

i) MM signalling via A or lu interface 

If the VLR receives a Location Update request or an IMSI detach indication from the UE by the A or lu interface 
when the state of the SGs association in the VLR is not SGs-NULL, the VLR shall move the state of the SGs 
association to SGs-NULL. 

ii) Additional Location Update Request 

If the state of the SGs association in the VLR is LA-UPDATE PRESENT and an SGsAP-LOCATION- 
UPDATE-REQUEST message is received, then: 

if the message is from the same MME and indicates the same New location area identifier information 
element as the outstanding location update request, then the VLR shall ignore this additional SGsAP- 
LOCATION-UPDATE-REQUEST message; 
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if the message is from the same MME but indicates a different New location area identifier information 
element to the outstanding location update request, then the VLR shall treat this additional SGsAP- 
LOCATION-UPDATE-REQUEST message and the VLR shall not send any response to the previous 
SGsAP-LOCATION-UPDATE-REQUEST message; or 

if the message is from a different MME (indicating either the same or different New location area identifier 
information element) to the outstanding location update request, then the VLR shall treat this additional 
SGsAP-LOCATION-UPDATE-REQUEST message and the VLR shall not send any response to the previous 
SGsAP-LOCATION-UPDATE-REQUEST message. 

iii) Detach signalling from the MME 

If the state of the SGs association in the VLR is LA-UPDATE PRESENT and either an SGsAP-EPS-DETACH- 
INDICATION or an SGsAP-IMSI-DETACH-INDICATION message is received, then the VLR shall abandon 
the Location Update for non-EPS services procedure (neither an SGsAP-LOCATION-UPD ATE- ACCEPT nor 
an SGsAP-LOCATION-UPDATE-REJECT messages is sent) and the further actions described in 
subclauses 5.4 or 5.5 or 5.6 are followed. 

iv) Signalling via Gs interface 

If the VLR receives for a UE a BSSAP-n-LOCATION-UPDATE-REQUEST message (as defined in 

3GPP TS 29.018 [16]) from an SGSN when the state of the SGs association for this UE in the VLR is not SGs- 

NULL, the VLR shall move the state of the SGs association to SGs-NULL. 

5.3 Non-EPS alert procedure 

5.3.1 General description 

This procedure is used by the VLR to request from an MME an indication when any signalling activity from the UE is 
detected. This procedure can be invoked at any time by the VLR. The MME shall acknowledge the SGsAP- ALERT- 
REQUEST message. 

5.3.2 Procedures in the VLR 

5.3.2.1 Alert Initiation 

The VLR may start the Non-EPS alert procedure at any time. When the VLR wants to request from an MME that 
further activity from a UE is reported by the MME, the VLR shall send an SGsAP- ALERT-REQUEST message to that 
MME. The VLR starts timer Ts7 when the SGsAP-ALERT-REQUEST message is sent. 

5.3.2.2 Alert Response 

When an SGsAP-ALERT-ACK message is received, the VLR shall stop the timer Ts7. The state of the SGs association 
is not changed. 

5.3.2.3 Alert Failure 

If an SGsAP- ALERT-REJECT message is received, the VLR shall stop the timer Ts7, move the state of the SGs 
association to SGs-NULL and within this state the SGs association is marked with the contents of the SGs cause 
information element. 

5.3.2.4 Alert Indication 

The VLR shall not change the state of the SGs association upon reception of an SGsAP-UE- ACTIVITY-INDICATION 

message. 
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5.3.2.5 Abnormal cases 

If no SGsAP- ALERT- ACK message is received before the timer Ts7 expires, the VLR shall retransmit the SGs AP- 
ALERT-REQUEST message a maximum of Ns7 times. 

NOTE: If no SGsAP-ALERT-ACK message is received after that, a report is made to the O&M system. The state 
of the SGs association is not changed. 

5.3.3 Procedures in the MME 

5.3.3.1 Alert response 

The MME may receive an SGsAP-ALERT-REQUEST message in any state of the SGs association. Upon receipt of an 
SGsAP- ALERT-REQUEST message from the VLR and if the IMSI is known in the MME, the MME shall reply with 
an SGsAP-ALERT-ACK message and set the NEAF. 

5.3.3.2 Alert failure 

If an SGsAP-ALERT-REQUEST message is received for an IMSI that is unknown at the MME, the MME shall return 
an SGsAP-ALERT-REJECT message to the VLR indicating the SGs cause information element value "IMSI 
unknown". 

5.3.3.3 Alert indication 

The MME shall report to the VLR upon detection of any activity in E-UTRAN (either signalling or, indirectly detected 
via S-GW, data transfer) from the UE if the NEAF is set. If the MME detects EPS signalling that leads to a procedure 
towards the VLR, the MME shall follow this procedure and reset the NEAF. If the MME detects activity that does not 
lead to any procedure towards the VLR, the MME shall send an SGsAP-UE- ACTIVITY-INDICATION message 
towards the VLR and reset the NEAF. 

5.4 Explicit IMSI detach from EPS services 

5.4.1 General description 

This procedure is used by the MME to indicate to the VLR that the UE has been detached from EPS services and 
therefore the SGs association between the MME and the VLR has to be deactivated. This procedure only applies to UEs 
which are not in the SGs-NULL state at the MME. The procedures specified in this subclause apply to EPS detach 
indication initiated by the UE or by the network as specified in 3GPP TS 24.301 [14]. 

The procedure is also used by the MME to indicate to the VLR when a combined tracking area update procedure has 
been rejected by the MME. 

The Explicit IMSI detach from EPS services procedure aborts any other ongoing procedure related to this UE on the 
SGs interface in the MME and in the VLR. 

5.4.2 Procedures in the MME 
5.4.2.1 Explicit EPS detach indication 

The MME shall send an SGsAP-EPS-DETACH-INDICATION message to a VLR if: 

the MME receives a detach for EPS from the UE; 

the MME performs network initiated EPS detach procedure; or 

the combined tracking area update procedure is rejected by the MME. 

If the MME receives a Detach Request from a UE and the state of the SGs association to a VLR for that UE is not SGs- 
NULL, the MME shall check the detach type indicated in the message. If the UE has indicated EPS detach the MME 
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shall send an SGsAP-EPS-DETACH-INDICATION message to the VLR indicating "UE initiated detach from EPS 

services". 

If the MME decides to perform a network initiated detach procedure and the state of the SGs association to a VLR for 
that MS is not SGs-NULL, the MME shall send an SGsAP-EPS-DETACH-INDICATION message to the VLR 
indicating "MME initiated detach from EPS services". 

If the combined tracking area update procedure is rejected at the MME for a UE with an SGs association state different 
from SGs-NULL, the MME shall send an SGsAP-EPS-DETACH-INDICATION to the VLR indicating "EPS services 
not allowed". 

After sending of the SGsAP-EPS-DETACH-INDICATION message, the MME shall move the state of the SGs 
association to SGs-NULL. The MME shall start timer Ts8 upon transmission of the SGsAP-EPS-DETACH- 
INDICATION message and the MME shall stop and reset timer Ts6-1 if running. 

5.4.2.2 Explicit EPS detach response 

If a confirmation of the detach needs to be sent to the UE, the MME shall not wait for the reception of the SGsAP-EPS- 
DETACH-ACK message to send such confirmation. 

5.4.2.3 Abnormal cases 

If no SGsAP-EPS-DETACH-ACK message is received by the MME in response to a previous SGsAP-EPS-DETACH- 
INDICATION message before timer Ts8 expires, the MME shall repeat the SGsAP-EPS-DETACH-INDICATION 
message a maximum of Ns8 times. 

NOTE: If no SGsAP-EPS-DETACH-ACK message is received after that, a report is made to the O&M system. 
The state of the SGs association during the acknowledgement procedure remains SGs-NULL. 

5.4.3 Procedures in the VLR 

When a VLR receives an SGsAP-EPS-DETACH-INDICATION message, the VLR shall send an SGsAP-EPS- 
DETACH-ACK message to the sending MME. The VLR shall move the state of the SGs association for the UE from 
any state to SGs-NULL. The VLR marks the SGs association as "detached for EPS services" with the reason indicated 
in the IMSI detach from EPS service type information element. 

If the VLR"s implicit detach timer is not running then the VLR shall set and restart the implicit detach timer upon 
reception of an SGsAP-EPS-DETACH-INDICATION message. If the VLR"s implicit detach timer is running (the state 
of the SGs association was already SGs-NULL) then the reception of an SGsAP-EPS-DETACH-INDICATION 
message shall not affect VLR"s implicit detach timer. 

5.5 Explicit IIVISI detach from non-EPS services 
5.5.1 General description 

This procedure is used by the MME to indicate to the VLR that the UE has performed IMSI detach from non-EPS 
services and therefore the SGs association between the MME and the VLR has to be deactivated. This procedure applies 
only to UEs for which there is a SGs association at the MME. The procedures specified in this subclause apply only to 
IMSI detach or combined IMSI and EPS detach requests. 

The explicit IMSI detach from non-EPS services procedure aborts any other ongoing procedure related to this UE on 
the SGs interface in the MME and in the VLR. 

In order to ensure that the VLR and the UE are synchronized as to which paging channel to use for any of the 
subsequent paging events, the MME shall attempt to inform the VLR about the detach event by using a retry scheme if 
the initial dehvery of the SGsAP-IMSI-DETACH -INDICATION message fails. 
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5.5.2 Procedures in the MME 

5.5.2.1 Explicit IMSI detach initiation 

When an MME receives a Detach Request from a UE for which an SGs association exists, the MME shall check the 
detach type indicated. If the UE is indicating IMSI detach or combined EPS/IMSI detach the MME shall send an 
SGsAP-IMSI-DETACH-INDICATION message to the VLR indicating "Explicit UE initiated IMSI detach from non- 
EPS service" or "Combined EPS/IMSI detach explicit UE initiated IMSI detach from EPS and non-EPS services". 

After the sending of the SGsAP-IMSI-DETACH-INDICATION message to the VLR, the MME shall move the state of 
the SGs association to SGs-NULL. The MME shall start timer Ts9 upon transmission of the SGsAP-IMSI-DETACH- 
INDICATION message and the MME shall stop and reset timer Ts6-1, if running. 

5.5.2.2 Explicit IMSI detach response 

If the detach type received from the UE indicated IMSI only detach or combined EPS/IMSI detach not due to switch 
off, the MME shall wait for the reception of the SGsAP-IMSI-DETACH-ACK message before sending the 
confirmation of the detach to the UE. 

5.5.2.3 Abnormal cases 

The following abnormal cases can be identified: 

i) no SGsAP-IMSI-DETACH-ACK received for a detach with switch off 

If the MME sent an SGsAP-IMSI-DETACH-INDICATION message for a combined IMSI and EPS detach due 
to switch off and timer Ts9 expires, the MME shall repeat the SGsAP-IMSI-DETACH-INDICATION message a 
maximum of Ns9 times. 

ii) no SGsAP-IMSI-DETACH-ACK received for a detach with no switch off 

If the MME sent an SGsAP-IMSI-DETACH-INDICATION message for an IMSI only detach or a combined 
IMSI and EPS detach not due to switch off and timer Ts9 expires, the MME shall repeat the SGsAP-IMSI- 
DETACH-INDICATION message a maximum of Ns9 times. If no SGsAP-IMSI-DETACH-ACK is received 
after that the MME shall send the confirmation of the detach to the UE. 

5.5.3 Procedures in tine VLR 

When a VLR receives an SGsAP-IMSI-DETACH-INDICATION message, the VLR shall send an SGsAP-IMSI- 
DETACH-ACK message to the sending MME. The VLR shall move the state of the SGs association for the UE from 
any state to SGs-NULL. If the SGsAP-IMSI-DETACH-INDICATION message indicated "Explicit UE initiated IMSI 
detach from non EPS service", the VLR marks the SGs association as "IMSI detached for non-EPS services". If the 
SGsAP-IMSI-DETACH-INDICATION message indicated "Combined explicit UE initiated IMSI detach from EPS and 
non-EPS services", the VLR marks the SGs association as "IMSI detached for EPS and non-EPS services". 

5.6 Implicit IMSI detach from non-EPS services 
5.6.1 General description 

This procedure is used by the MME to indicate when an internal MME timer mechanism has caused the MME to delete 
the EMM context of an UE or mark its EMM context as detached. This procedure only applies to UEs for which there is 
an SGs association at the MME. 

The implicit IMSI detach from non-EPS services procedure aborts any other ongoing procedure related to this UE on 
the SGs interface in the MME and in the VLR. 

In order to ensure that the VLR and the UE are synchronized as to which paging channel to use for any of the 
subsequent paging events the MME shall attempt to inform the VLR about the detach event by using a retry scheme if 
the initial delivery of the SGsAP-IMSI-DETACH-INDICATION message fails. 
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5.6.2 Procedures in the MME 

When the impHcit IMSI detach from non-EPS services procedure is started for a UE by the above mentioned internal 
MME timer mechanism, the MME shall send an SGsAP-IMSI-DETACH-INDICATION message to the VLR 
indicating "Implicit MME initiated IMSI detach from non-EPS service". 

After the sending of the SGsAP-IMSI-DETACH -INDICATION message, the MME shall move the state of the SGs 
association to SGs-NULL. The MME shall start timer TslO upon transmission of the SGsAP-IMSI-DETACH- 
INDICATION message. 

If no SGsAP-IMSI-DETACH-ACK message is received by the MME to a previous SGsAP-IMSI-DETACH- 
INDICATION message before timer TslO expires, the MME shall repeat the SGs AP-IMSI-DETACH -INDICATION 
message a maximum of NslO times. The state of the SGs association during the acknowledgement procedure remains 
SGs-NULL. 

5.6.3 Procedures in tine VLR 

When a VLR receives the SGsAP-IMSI-DETACH -INDICATION message and the state of the SGs association is not 
SGs-NULL, the VLR shall move the state of the SGs association for the UE to SGs-NULL. The VLR marks the SGs 
association as "IMSI implicitly detached for EPS and non-EPS services". The VLR shall also send an SGsAP-IMSI- 
DETACH- ACK message to the sending MME. 

5.7 VLR failure procedure 

5.7.1 General description 

This procedure is used by the VLR to inform the MMEs with an SGs association about the recovery from an internal 
failure that has affected the SGs association with the MMEs. 

NOTE: The VLR recovery procedure is handled in such a way that the signalling load on the VLR and MMEs 
does not create any overload problem. 

5.7.2 Procedures in the VLR 

5.7.2.1 VLR Reset Initiation 

In the event of a failure at the VLR which has resulted in the loss of the SGs association information for some UEs, the 
VLR shall move from any state to the SGs-NULL state for all the SGs associations with MMEs per UE. The VLR shall 
also set the "Confirmed by Radio Contact" restoration indicator to "false" (see 3GPP TS 23.007 [4]). The VLR shall not 
send any SGsAP-MM-INFORMATION-REQUEST messages to UEs with the SGs association in the SGs-NULL state. 

When the VLR restarts, the VLR shall send an SGsAP-RESET-INDICATION message to all the MMEs connected to 
the VLR by the SGs interface. This message indicates to the MME that for the UEs with an SGs association to that 
VLR, the SGs associations are no longer reliable. The VLR shall also start a separate timer Tsll for each MME. 

5.7.2.2 VLR Reset Response 

Upon receipt of an SGs AP -RESET- ACK message from an MME, the VLR shall stop the timer Tsll for that MME. 

5.7.2.3 Abnormal cases 

If the VLR does not receive an SGsAP-RESET-ACK message from that MME before the timer Tsl 1 expires, the VLR 
shall retransmit the SGsAP-RESET-INDICATION message. The retransmission is repeated a maximum of Nsll times. 

NOTE: If no SGsAP-RESET-ACK is received after that a report is made to the O&M system. 
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5.7.3 Procedures in the MME 

Upon receipt of an SGsAP-RESET-INDICATION message from the VLR, the MME is informed that all the SGs 
associations with that VLR for all the UEs registered in the MME are no longer reliable because the VLR has lost 
information about the state of the UEs and during the failure the VLR might have missed signalling messages. The 
MME shall set the "VLR-Reliable" MM context variable to "false". The detach procedures for deleting the SGs 
association are still applicable (see subclauses 5.4, 5.5 and 5.6). If the "VLR-Reliable" MM context variable is set to 
"false", upon reception of a Combined Tracking Area update request or a periodic Tracking Area Update from the UE 
that is attached for non-EPS service, the MME may request the re-attach to non-EPS services, or may alternatively 
immediately perform the Location Update for non-EPS services procedure towards the VLR as described in 
subclause 5.2. 

The MME sends an SGsAP-RESET-ACK message to the VLR. 

5.8 MME failure procedure 

5.8.1 General description 

This procedure is used by the MME to inform the associated VLRs about the recovery from an internal failure that has 
affected the SGs association with the VLRs. 

NOTE: The MME recovery procedure is handled in such a way that the signalling load on the MME and VLRs 
does not create any overload problem. 

5.8.2 Procedures in the MME 

5.8.2.1 MME Reset Initiation 

In the event of a failure at the MME which has resulted in the loss of the SGs association information on some UEs, the 
MME shall move from any state to the SGs-NULL state all the SGs associations with VLRs per UE. The MME shall 
also set the "MME-Reset" MM context variable to "true" and start the timer Tsl2-L When the timer Tsl2-1 expires the 
"MME-Reset" MM context variable is set to "false". 

The MME shall send an SGsAP-RESET-INDICATION message to all the VLRs connected to the MME by SGs 
interfaces. The SGsAP-RESET-INDICATION message indicates to the VLR that all the SGs associations with that 
particular MME for all the UEs registered in the VLR are no longer reliable. The normal procedures for updating the 
SGs association are still applicable (see subclauses 5.2, 5.4, 5.5 and 5.6). The MME shall also start a separate 
timer Tsl2-2 for each VLR. 

5.8.2.2 MME Reset Response 

Upon receipt of an SGsAP-RESET-ACK message, the MME shall stop the timer Tsl2-2 for that VLR. 

5.8.2.3 Abnormal cases 

If the MME does not receive an SGsAP-RESET-ACK message from that VLR before the timer Tsl2-2 expires, the 
MME shall retransmit the SGsAP-RESET-INDICATION message. 

NOTE: If no SGsAP-RESET-ACK is received after that a report is made to the O&M system. 

5.8.3 Procedures in the VLR 

Upon receipt of an SGsAP-RESET-INDICATION message from the MME, the VLR is informed that all the SGs 
associations with that MME for all the UEs registered in the MME are no longer reliable because the MME has lost 
information about the state of the UEs for that VLR and during the failure the MME might have missed signalling 
messages. The VLR shall set the "Confirmed by Radio Contact" restoration indicator to "false" in all the SGs 
associations containing the restarted MME. If the "Confirmed by Radio Contact" restoration indicator is "false" the 
VLR may send paging messages on both the SGs and the A/Iu interface. 
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The VLR sends an SGsAP-RESET-ACK message to the MME. This indicates to the MME that all the SGs associations 
for the UEs which have a SGs association with that MME will be moved to the SGs-NULL state. 

5.9 HSS failure 

5.9.1 General description 

This subclause describes the MME behaviour towards the VLR as a consequence of an HSS reset. 

In the case of an HSS failure, the HSS informs the associated MMEs about the recovery from an internal failure that has 
affected the SGs association with the MMEs according to the HSS reset procedure specified in 3GPP TS 29.272 [17]. 

This information is used in the MME to trigger the VLR to perform a location update towards the HSS in order to 
restore the HSS subscriber data. 

5.9.2 Procedures in the MME 

Upon receipt of a HSS reset indication from the HSS, the MME shall set the NEAP for all registered UEs in the MME 
for which a valid SGs association with a VLR exists. 

Upon detection of any signalling activity from the UE, the MME shall report to the VLR if the NEAP, as defined in 
subclause 5.3.3, is set for this UE. If the MME detects signalling that leads to a procedure towards the VLR, the MME 
shall follow this procedure and reset the NEAP. If the MME detects activity that does not lead to any procedure towards 
the VLR, the MME shall send an SGsAP-UE- ACTIVITY-INDICATION message towards the VLR and reset the 
NEAP. The MME may delay sending the activity indication for a maximum operator-configuration depending time 
period to avoid high signalling load. 

5.10 MM information procedure 

5.10.1 General description 

The MM information procedure is performed between the VLR and the MME via the SGs interface if the target UE for 
the MM information procedure is IMSI attached to both EPS and non-EPS services (i.e. the state of the SGs association 
is SGs-ASSOCIATED). The outcome of the MM Information procedure does not change the state of the SGs 
association at the VLR or MME. 

5.1 0.2 Procedures in the VLR 

If for the target UE for the MM information procedure the state of the SGs association in the VLR is SGs- 
ASSOCIATED, the VLR may initiate the MM information procedure by transferring an SGsAP-MM- 
INPORMATION-REQUEST message to the MME. 

5.1 0.3 Procedures in the MME 

If an SGsAP-MM-INPORMATION-REQUEST message is received for a UE for which there exists an SGs association 
at the MME, the MME shall forward the contents of the MM information information element to the UE indicated in 
the SGsAP-MM-INPORMATION-REQUEST message, using an EMM INPORMATION message as defined in 
3GPPTS 24.301 [14]. 

5.1 1 Procedure for tunnelling of NAS messages 
5.11.1 General description 

The tunnelling of NAS messages procedure is used to encapsulate the NAS messages exchanged between the UE and 
the VLR. This procedure can be used by either the VLR or the MME depending on the direction of the NAS message. 
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The two procedures are identified as uplink unitdata, in the direction from the MME to the VLR, and downhnk unitdata 
in the direction from the VLR to the MME. 

5.11.2 Uplink unitdata procedure 

5.11.2.1 Procedures in the MME 

When the MME receives an UpHnk NAS Transport message (see 3GPP TS 24.301 [14]) from a UE, the MME shall 
copy the value part of the NAS message container information element to the value part of the NAS message container 
information element of the SGsAP-UPLINK-UNITDATA message and send the SGsAP-UPLINK-UNITDATA 
message to the VLR. 

5.11.2.2 Procedures in the VLR 

Upon reception of an SGsAP-UPLINK-UNITDATA, the VLR shall extract the NAS message container information 
element and treat the value part of this information element according to the procedures defined in 
3GPPTS 24.011 [10]. 

5.1 1 .2.3 Abnormal cases 

The following abnormal case can be identified: 

i) if there is no SGs association for the UE at the VLR 

If the VLR receives an SGsAP-UPLINK-UNITDATA from the MME for a UE for which no SGs association 
exists, then the VLR shall ignore the received message. 

5.1 1 .3 Downlink unitdata procedure 

5.11.3.1 Procedures In the VLR 

When the VLR needs to send a NAS message to the UE, the VLR shall first verify whether or not it has an SGs 
association for the UE. If the state of the SGs association for the UE is SGs-ASSOCIATED and LA-UPDATE- 
PRESENT, then the VLR continues with the procedure. The VLR shall build and encapsulate the NAS message into the 
value part of the NAS message container information element of an SGsAP-DOWNLINK-UNITDATA message and 
send the SGsAP-DOWNLINK-UNITDATA message to the MME. 

5.1 1 .3.2 Procedures in the MME 

Upon reception of an SGsAP-DOWNLINK-UNITDATA message, the MME shall copy the value part of the NAS 
message container information element to the value part of the NAS message container information element of a 
Downlink NAS Transport message (see 3GPP TS 24.301 [14]) and send the Downlink NAS Transport message to the 
UE. 

5.11.3.3 Abnormal cases 

The following abnormal case can be identified: 

i) if there is no SGs association for the UE at the MME 

If the MME receives an SGsAP-DOWNLINK-UNITDATA message from the VLR for a UE for which there is 
no SGs association, then the MME shall ignore the received message. 



5.1 1 .4 Release procedure 



When the VLR determines that there are no more NAS messages to be exchanged between the VLR and the UE, the 
VLR shall send the SGsAP-RELEASE-REQUEST message to the MME, including the IMSI of the UE for which there 
are no more NAS messages to be tunnelled. 
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NOTE: For the SMS transport, the VLR can send the SGsAP-RELEASE-REQUEST message when the SMS 

transaction is complete (reception of a CP-ACK message for the MO case, sending of a CP-ACK message 
for the MT case), upon reception of a CP-ERROR message, abort of SMS transaction by upper layers, or 
upon some error cases such as TCI expiry. 

This indication can be used by the MME to control the release of the NAS signalling connection with the UE indicated 
in the SGsAP-RELEASE-REQUEST message. 

5.12 Service request procedure 

5.12.1 General description 

After the reception of an SGsAP-P AGING-REQUEST message from the VLR, the MME will use this procedure to 
indicate to the VLR that a NAS signalling connection exists between the UE and the MME. The procedure can be 
invoked, by the MME, either upon reception of a Service Request message from the UE or directly after receiving the 
SGsAP-P AGING-REQUEST message from the VLR, based on the UE"s EMM mode. 

5.1 2.2 Procedures in tine MME 

When receiving the SGsAP-P AGING-REQUEST message, the MME shall first check whether the UE, for which the 
paging is sent, is in EMM-IDLE or EMM-CONNECTED mode. 

If the UE is in EMM-CONNECTED mode, the MME shall immediately create and send an SGsAP-SER VICE- 
REQUEST message to the VLR with the service indicator corresponding to what is received from the SGsAP- 
PAGING-REQUEST message. 

If the UE is in EMM-IDLE Mode, the MME shall map the IMSI, provided in the SGsAP-PAGING-REQUEST 
message, to the S-TMSI and then take the actions as described in 3GPP TS 24.301 [14] subclause 5.6.2.2.1. The area in 
which the MME shall page the UE is defined in the subclause 5.1.3. Then, upon reception of the Service Request 
message, from the UE, the MME shall send the SGsAP-SERVICE-REQUEST message to the VLR. 

If the MME fails to map the IMSI to the S-TMSI, the MME shall send an SGsAP-P AGING-REJECT message, with the 
SGs cause information element indicating "UE unreachable", to the VLR. 

5.1 2.3 Procedures in tine VLR 

Upon reception of the SGs AP-SER VICE-REQUEST message, the VLR shall stop Timer Ts5 and consider the paging 
procedure as successful. If the paging procedure is for SMS, the VLR shall then start the delivery of the SMS 
message(s) according to the subclause 5.11.3.1. 



SGs transport 



6.1 General 

This subclause specifies the standards for signalling transport to be used across SGs interface. SGs interface is a logical 
interface between the MME and the VLR. All the SGsAP messages described in the present document require an SCTP 
association between the MME and the VLR. 

6.2 IP layer 

The MME and the VLR shall support IPv6 (see IETF RFC 2460 [22]) and/or IPv4 (see IETF RFC 791 [20]). 
The IP layer of SGs only supports point-to-point transmission for delivering SGsAP messages. 
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6.3 Transport layer 

SCTP (see IETF RFC 4960 [23]) shall be supported as the transport layer of SGsAP messages. 

Transport network redundancy can be achieved by SCTP multi-homing between two end-points, of which one or both is 
assigned with multiple IP addresses. SCTP end-points shall support a multi-homed remote SCTP end-point. For SCTP 
endpoint redundancy, an SCTP endpoint (in the MME or VLR) may send an INIT, at any time for an already 
established SCTP association, which the other SCTP endpoint shall handle as defined in IETF RFC 4960 [23]. 

The MME shall establish only one SCTP association for each MME /VLR pair. 

Within the SCTP association established between one MME and one VLR, both MME and VLR shall reserve several 
stream identifiers, based on the INIT message exchange for the sole use of SGsAP procedures. 

The MME shall estabUsh the SCTP association. 

The registered port number for SGsAP is XXXX. 

Editor's note; The port number for SGsAP will be assigned by lANA once this specification is issued. 
The registered payload protocol identifier for SGsAP is XX. 

Editor's note: The payload protocol identifier for SGsAP will be assigned by lANA once this specification is issued. 



Error handling 



7.1 General 

This subclause specifies procedures for the handling of unknown, unforeseen, and erroneous protocol data by the 
receiving entity (i.e. the MME or the VLR). These procedures are called "error handling procedures", but in addition to 
providing recovery mechanisms for error situations they define a compatibility mechanism for future extensions of the 
protocol. 

In this subclause the following terminology is used: 

an information element is defined to be syntactically incorrect in a message if it contains at least one value 
defined as "reserved", or if its value part violates coding rules. However, it is not a syntactical error that an 
information element indicates in its Length Indicator a greater length than defined in the relevant subclause; and 

a message is defined to have semantically incorrect contents if it contains information which, possibly dependant 
on the state of the receiver, is in contradiction to the resources of the receiver and/or to the procedural part of 
current specification. 

When a receiving entity detects the need to send an SGsAP-STATUS message (see errors detailed below), the entity 
shall copy the IMSI information element value (if included) of the incorrect message to the IMSI information element 
of the SGsAP-STATUS message. The message in error is also included in the SGsAP-STATUS message. Both the 
receiving and the sending entity shall abandon the procedure related to the incorrect message and return to the state 
from where the procedure related to the incorrect message was started. 

Both the receiving and the sending entity shall inform the O&M entity upon sending or receiving an SGsAP-STATUS 

message. 

The next subclauses shall be applied in order of precedence. 



7.2 Message too short 



When the receiving entity receives a message that is too short to contain a complete message type information element, 
the receiving entity shall ignore that message. 
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7.3 Unknown or unforeseen message type 

The entity receiving a message with a message type not defined or not implemented shall ignore the message. The 
receiving entity shall return an SGsAP-STATUS message with the SGs cause information element set to "message 
unknown" and the Erroneous message information element containing the received message. 

The entity receiving a message that is not compatible with the protocol state shall return an SGsAP-STATUS message 
with the SGs cause information element set to "message not compatible with the protocol state" and the erroneous 

message. 

The entity receiving a message that is not defined to be received by that entity (i.e. the message is sent in the wrong 
direction) shall treat the message as unknown message and shall ignore the message. The entity shall return an SGsAP- 
STATUS message with the SGs cause information element set to "message unknown" and the Erroneous message 
information element containing the received message. 

7.4 Missing mandatory information element 

When the receiving entity diagnoses a "missing mandatory information element" error, the receiving entity shall ignore 
the message and return an SGsAP-STATUS message with the SGs cause information element set to "missing 
mandatory information element" and shall return the Erroneous message information element containing the received 

message. 

7.5 Information elements unknown or unforeseen in the 
message 

The receiving entity shall ignore all information elements unknown or unforeseen in a message. 

7.6 Out of sequence information elements 

The receiving entity shall ignore all information elements that are out of sequence. 

7.7 Repeated information elements 

If an information element with format T, TV, or TLV is repeated in a message in which repetition of the information 
element is not specified, the receiving entity shall only handle the contents of the information element appearing first 
and shall ignore all subsequent repetitions of the information element. When repetition of information elements is 
specified, the receiving entity shall only handle the contents of specified repeated information elements. If the limit on 
repetition of information elements is exceeded, the receiving entity shall handle the contents of information elements 
appearing first up to the limit of repetitions and shall ignore all subsequent repetitions of the information element. 

7.8 Syntactically incorrect mandatory information element. 

On receipt of a message which contains a syntactically incorrect mandatory information element, the receiver shall 
ignore the message and return an SGsAP-STATUS message with the SGs cause information element set to "invalid 
mandatory information" and shall return the Erroneous message information element containing the received message. 

7.9 Syntactically incorrect optional information elements 

The receiving entity shall treat all optional information elements that are syntactically incorrect in a message as not 
present in the message. 



£75/ 



3GPP TS 29.118 version 8.1.0 Release 8 



30 



ETSI TS 129 118 V8.1.0 (2009-04) 



7.10 Conditional information element errors 

When the entity receiving a message diagnoses a "missing conditional information element" error or an "unexpected 
conditional information element" error or when it receives a message containing at least one syntactically incorrect 
conditional information element which is required to be present in the message, the receiving entity shall ignore the 
message and return an SGsAP-STATUS message with the SGs cause information element set to "conditional 
information element error" and shall return the Erroneous message information element containing the received 
message. 

When the entity receives a message containing a syntactically incorrect conditional information element which is not 
required to be present in the message, nor required to be absent in the message, then the receiving entity shall ignore 
that information element. 

7.1 1 Information elements with semantically incorrect contents 

When an information element with semantically incorrect contents is received, the foreseen reactions of the procedural 
part of the present specification are performed. 

If however no such reactions are specified, the receiving entity shall ignore that information element and treat the rest of 
the message. If, because this information element was ignored, the rest of the message can no longer be handled then 
the receiving entity shall return an SGsAP-STATUS message with the SGs cause information element set to 
"semantically incorrect message" and shall return the Erroneous message information element containing the received 

message. 



8 Message functional definitions and contents 

8.1 SGsAP-ALERT-ACK message 

This message is sent by the MME to the VLR to acknowledge a previous SGsAP-ALERT-REQUEST message. 
Table 8.1.1 shows the content of the SGsAP- ALERT- ACK message. 

Table 8.1.1 : SGsAP-ALERT-ACK message content 



Information element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
9.2 


M 


V 


1 


IMSI 


IMSI 
9.4.6 


M 


TLV 


6-10 



8.2 SGsAP-ALERT-REJECT message 

This message is sent from the MME to the VLR to indicate that the MME could not identify the IMSI indicated in the 
SGsAP-ALERT-REQUEST message. Table 8.2.1 shows the content of the SGsAP-ALERT-REJECT message. 

Table 8.2.1 : SGsAP-ALERT-REJECT message content 



Information element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
9.2 


M 


V 


1 


IMSI 


IMSI 
9.4.6 


M 


TLV 


6-10 


SGs Cause 


SGs cause 
9.4.18 


M 


TLV 


3 



£75/ 



3GPP TS 29.118 version 8.1.0 Release 8 



31 



ETSI TS 129 118 V8.1.0 (2009-04) 



8.3 SGsAP-ALERT-REQUEST message 

This message is sent by the VLR to the MME to request an indication when the next activity of a UE is detected. 
Table 8.3.1 shows the content of the SGsAP-ALERT-REQUEST message. 

Table 8.3.1 : SGsAP-ALERT-REQUEST message content 



Information element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
9.2 


M 


V 


1 


IMSI 


IMSI 
9.4.6 


M 


TLV 


6-10 



8.4 SGsAP-DOWNLINK-UNITDATA message 

This message is sent from the VLR to the MME to transparently relay a NAS message, from the VLR, to the UE. 
Table 8.4.1 shows the content of the SGsAP-DOWNLlNK-UNITDATA message. 

Table 8.4.1 : SGsAP-DOWNLINK-UNITDATA message content 



Information element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
9.2 


M 


V 


1 


IMSI 


IMSI 
9.4.6 


M 


TLV 


6-10 


NAS message container 


NAS message container 
9.4.15 


M 


TLV 


4-253 



8.5 SGsAP-EPS-DETACH-ACK message 

This message is sent by the VLR to the MME to acknowledge a previous SGsAP-EPS -DETACH -INDICATION 
message. Table 8.5.1 shows the content of the SGsAP-EPS-DETACH-ACK message. 

Table 8.5.1 : SGsAP-EPS-DETACH-ACK message content 



Information element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
9.2 


M 


V 


1 


IMSI 


IMSI 
9.4.6 


M 


TLV 


6-10 



8.6 SGsAP-EPS-DETACH-INDICATION message 

This message is sent by the MME to the VLR to indicate an EPS detach performed from the UE or the MME. The type 
of detach is indicated in the IMSI detach from EPS service type information element. Table 8.6.1 shows the content of 
the SGsAP-EPS-DETACH-INDICATION message. 
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Table 8.6.1 : SGsAP-EPS-DETACH-INDICATION message content 



Information element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
9.2 


M 


V 


1 


IMSI 


IMSI 
9.4.6 


M 


TLV 


6-10 


MME name 


MME name 
9.4.13 


M 


TLV 


52-53 


IMSI detach from EPS service type 


IMSI detach from EPS service type 
9.4.7 


M 


TLV 


3 



8.7 SGsAP-IMSI-DETACH-ACK message 

This message is sent by the VLR to the MME to acknowledge a previous SGsAP-IMSI-DETACH-INDICATION 
message. Table 8.7.1 shows the content of the SGsAP-IMSI-DETACH-ACK message. 

Table 8.7.1 : SGsAP-IMSI-DETACH-ACK message content 



Information element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
9.2 


M 


V 


1 


IMSI 


IMSI 
9.4.6 


M 


TLV 


6-10 



8.8 SGsAP-IMSI-DETACH-INDICATION message 

This message is sent by the MME to the VLR to indicate an IMSI detach performed from the UE. The type of detach is 
indicated in the IMSI detach from non-EPS service type information element. Table 8.8.1 shows the content of the 
SGsAP-IMSI-DETACH-INDICATION message. 

Table 8.8.1 : SGsAP-IMSI-DETACH-INDICATION message content 



Information element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
9.2 


M 


V 


1 


IMSI 


IMSI 
9.4.6 


M 


TLV 


6-10 


MME name 


MME name 
9.4.13 


M 


TLV 


52-53 


IMSI Detach from non-EPS service 
type 


IMSI detach from non-EPS service 

type 

9.4.8 


M 


TLV 


1 



8.9 SGsAP-LOCATION-UPDATE-ACCEPT message 
8.9.1 Message definition 

This message is sent by the VLR to the MME to indicate that update or IMSI attach in the VLR has been completed. 
Table 8.9.1.1 shows the content of the SGsAP-LOCATION-UPDATE-ACCEPT message. 
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Table 8.9.1.1 : SGsAP-LOCATION-UPDATE-ACCEPT message content 



Information element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
9.2 


M 


V 


1 


IMSI 


IMSI 
9.4.6 


M 


TLV 


6-10 


Location area identifier 


Location area identifier 
9.4.11 


M 


TLV 


7 


New IMSI, or IMSI 


Mobile identity 
9.4.14 





TLV 


6-10 



8.9.2 NewTMSI,orlMSI 

This information element represents the identity to be used for (and then by) the UE. 

If this information element is an IMSI, then the UE is not allocated any TMSI (and deletes any TMSI accordingly). If 
this information element is a TMSI, then the UE will use this TMSI as the new temporary identity (the UE deletes its 
old TMSI and stores the new TMSI). If neither a TMSI nor an IMSI are included in this information element, the old 
TMSI, if any available, will be kept. 

8.10 SGsAP-LOCATION-UPDATE-REJECT message 

This message is sent by the VLR to the MME to indicate that location update or IMSI attach has failed. Table 8. 10. 1 
shows the content of the SGsAP-LOCATION-UPDATE-REJECT message. 

Table 8.10.1 : SGsAP-LOCATION-UPDATE-REJECT message content 



Information element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
9.2 


M 


V 


1 


IMSI 


IMSI 
9.4.6 


M 


TLV 


6-10 


Reject cause 


Reject cause 
9.4.16 


M 


TLV 


3 
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8.1 1 SGsAP-LOCATION-UPDATE-REQUEST message 
8.11.1 Message definition 

This message is sent by the MME to the VLR either to request update of its location file (normal update) or to request 
IMSI attach. Table 8.11.1.1 shows the content of the SGsAP-LOCATION -UPDATE-REQUEST message. 

Table 8.11.1.1: SGsAP-LOCATION-UPDATE-REQUEST message content 



Information element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
9.2 


M 


V 


1 


IMSI 


IMSI 
9.4.6 


M 


TLV 


6-10 


MME name 


MME name 
9.4.13 


M 


TLV 


52-53 


EPS location update type 


EPS location update type 
9.4.2 


M 


TLV 


3 


New location area identifier 


Location area identifier 
9.4.11 


M 


TLV 


7 


Old location area identifier 


Location area identifier 
9.4.11 





TLV 


7 


TMSI status 


TMSI status 
9.4.21 





TLV 


3 


IMEISV 


IMEISV 
9.4.5 





TLV 


10 



8.1 1 .2 0\6 location area icdentifier 

The MME shall include this information element if the UE included the old location area information in the ATTACH 
REQUEST or TRACKING AREA UPDATE REQUEST message. 

8.11.3 TMSI Status 

The MME shall include this information element if the TMSI status received in the ATTACH REQUEST or 
TRACKING AREA UPDATING REQUEST message from the UE indicates that no valid TMSI is available in the UE. 

8.11.4 IMEISV 

The MME shall include this information element if the MME supports the "Provision of UE Specific Behaviour 
Information to Network Entities". 

8.12 SGsAP-MM-INFORMATION-REQUEST 

This message is sent by the VLR to the MME to provide the UE with subscriber specific information. Table 8.12.1 
shows the content of the SGsAP-MM-INFORMATION-REQUEST message. 

Table 8.12.1 : SGsAP-MM-INFORMATION-REQUEST message content 



Information element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
9.2 


M 


V 


1 


IMSI 


IMSI 
9.4.6 


M 


TLV 


6-10 


MM information 


MM information 
9.4.12 


M 


TLV 


3-n 
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8.13 SGsAP-PAGING-REJECT message 

This message is sent from the MME to the VLR to indicate that the dehvery of a previous SGsAP-P AGING-REQUEST 
message has failed. Table 8.13.1 shows the content of the SGsAP-P AGING-REJECT message. 

Table 8.13.1 : SGsAP-PAGING-REJECT message content 



Information element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
9.2 


M 


V 


1 


IMSI 


IMSI 
9.4.6 


M 


TLV 


6-10 


SGs Cause 


SGs Cause 
9.4.18 


M 


TLV 


3 



8.14 SGsAP-PAGING-REQUEST message 
8.14.1 Message definition 

This message is sent from the VLR to the MME and contains sufficient information to allow the paging message to be 
transmitted by the correct cells at the correct time. Table 8.14.1.1 shows the content of the SGs AP-P AGING- 
REQUEST message. 

Table 8.14.1.1 : SGsAP-PAGING-REQUEST message content 



Information element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
9.2 


M 


V 


1 


IMSI 


IMSI 
9.4.6 


M 


TLV 


6-10 


VLR name 


VLR name 


M 


TLV 


3-n 


Service indicator 


Service indicator 
9.4.17 


M 


TLV 


3 


TMSI 


TMSI 
9.4.20 





TLV 


6 


CLI 


CLI 

9.4.1 





TLV 


3-14 


Location area identifier 


Location area identifier 
9.4.11 





TLV 


7 


Global CN-ld 


Global CN-ld 
9.4.4 





TLV 


7 


SS code 


SS code 
9.4.19 





TLV 


3 


LCS indicator 


LCS indicator 
9.4.10 





TLV 


3 


LCS client identity 


LCS client identity 
9.4.9 





TLV 


3-n 


Channel needed 


Channel needed 
9.4.23 





TLV 


3 


eMLPP Priority 


eMLPP Priority 
9.4.24 





TLV 


3 



8.14.2 TMSI 

This element is omitted in the exceptional case where paging with IMSI is performed. 
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8.14.3 CLI 

If the Calling Line Identification is available in the VLR, the VLR shall include this information element. 

8.14.4 Location area identifier 

The VLR shall include this information element if the "Confirmed by Radio Contact" restoration indicator is set to 
"true". 

8.14.5 Global CN-ld 

If the network supports the Intra Domain Connection of RAN Nodes to multiple CN Nodes functionality, the VLR shall 
include this information element when the VLR initiates paging by IMSI, via the SGs interface. 

8.14.6 SScode 

The VLR shall include this information element if paging is due to a NW-initiated Call Independent SS procedure (see 
3GPPTS 24.010 [9]). 

8.14.7 LCS indicator 

The VLR shall include this information element if the paging is due to a Mobile Terminated Location Request (see 
3GPPTS 24.030 [11]). 

8.14.8 LCS client identity 

The VLR shall include this information element if the paging is due to a Mobile Terminated Location Request (see 
3GPPTS 24.030 [11]). 

8.14.9 Channel needed 

This information element shall be included if the VLR intends to indicate which channel the UE should use. 

8.14.10 eMLPP priority 

This information element shall be included if the subscriber has a subscription for eMLPP and the VLR intends to 
indicate eMLPP priority to the UE. 

8.15 SGsAP-RESET-ACK message 
8.15.1 Message definition 

This message is sent from the MME or the VLR to acknowledge a previous SGsAP-RESET-INDICATION message. 
This message indicates that all the SGs associations to the VLR or the MME have been marked as invalid. 

The sending entity (either MME or VLR) includes its identity in the form of a name in the SGsAP-RESET-ACK 
message. Table 8.15.1.1 shows the content of the SGsAP-RESET-ACK message. 
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Table 8.15.1.1 : SGsAP-RESET-ACK message content 



Information element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
9.2 


M 


V 


1 


MME name 


MME name 
9.4.13 


C 


TLV 


3-n 


VLR name 


VLR name 
9.4.22 


C 


TLV 


3-n 



8.15.2 MME name 

If the MME is the sending entity, then the MME shall indicate its identity by including its MME name information 
element. Otherwise (i.e. if the VLR is the sending entity), then the VLR shall not include the MME name information 
element. 

8.15.3 VLR name 

If the VLR is the sending entity, then the VLR shall indicate its identity by including its VLR name information 
element. Otherwise (i.e. if the MME is the sending entity), then MME shall not include the VLR name information 
element. 

8.16 SGsAP-RESET-INDICATION message 
8.16.1 Message definition 

This message is sent from the VLR to the MME to indicate that a failure in the VLR has occurred and all the SGs 
associations to the VLR are be marked as invalid. 

This message is also sent from the MME to the VLR to indicate that a failure in the MME has occurred and all the SGs 
associations to the MME are be marked as invalid. 

The sending entity (either MME or VLR) includes its identity in the SGsAP-RESET-INDICATION message. 
Table 8.16.1.1 shows the content of the SGsAP-RESET-lNDlCATION message. 

Table 8.16.1.1 : SGsAP-RESET-INDICATION message content 



Information element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
9.2 


M 


V 


1 


MME name 


MME name 
9.4.13 


C 


TLV 


52-53 


VLR name 


VLR name 
9.4.22 


C 


TLV 


3-n 



8.16.2 MME name 

If the MME is the sending entity, then the MME shall indicate its identity by including its MME name information 
element. Otherwise (i.e. if the VLR is the sending entity), then the VLR shall not include the MME name information 
element. 

8.16.3 VLR name 

If the VLR is the sending entity, then the VLR shall indicate its identity by including its VLR name information 
element. Otherwise (i.e. if the MME is the sending entity), then the MME shall not include the VLR name information 
element. 
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8.17 SGsAP-SERVICE-REQUEST message 

This message is sent from the MME to the VLR as a response to a previously received SGsAP-PAGING-REQUEST 
message for SMS to indicate the existence of a NAS signalHng connection between the UE and the MME. Table 8.17.1 
shows the content of the SGsAP-SER VICE-REQUEST message. 

Table 8.17.1 : SGsAP-SERVICE-REQUEST message content 



Information element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
9.1 


M 


V 


1 


IMSI 


IMSI 
9.4.6 


M 


TLV 


6-10 


Service indicator 


Service indicator 
9.4.17 


M 


TLV 


3 



8.18 SGsAP-STATUS message 
8.18.1 Message definition 

This message is sent by both the VLR and the MME to indicate an error. The contents of SGsAP-STATUS message are 
shown in table 8.18.1.1. 

Table 8.18.1.1 : SGsAP-STATUS message content 



Information element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
9.2 


M 


V 


1 


IMSI 


IMSI 
9.4.6 





TLV 


6-10 


SGs cause 


SGs cause 
9.4.18 


M 


TLV 


3 


Erroneous message 


Erroneous message 
9.4.3 


M 


TLV 


3-n 



8.18.2 IMSI 

The MME shall include this information element if the IMSI is present in the erroneous message. 

8.19 SGsAP-TMSI-REALLOCATION-COMPLETE message 

This message is sent by the MME to the VLR to indicate that TMSI reallocation on the UE has been successfully 
completed. Table 8.19.1 shows the content of the SGsAP-TMSI-REALLOCATION-COMPLETE message. 

Table 8.19.1 : SGsAP-TMSI-REALLOCATION-COMPLETE message content 



Information element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
9.2 


M 


V 


1 


IMSI 


IMSI 
9.4.6 


M 


TLV 


6-10 



8.20 SGsAP-UE-ACTIVITY-INDICATION message 

This message is sent by the MME to the VLR to indicate that activity from a UE has been detected. Table 8.20.1 shows 
the content of the SGsAP-UE- ACTIVITY-INDICATION message. 



£75/ 



3GPP TS 29.118 version 8.1.0 Release 8 



39 



ETSI TS 129 118 V8.1.0 (2009-04) 



Table 8.20.1 : SGsAP-UE-ACTIVITY-INDICATION message content 



Information element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
9.2 


M 


V 


1 


IMSI 


IMSI 
9.4.6 


M 


TLV 


6-10 



8.21 SGsAP-UE-UNREACHABLE message 

This message is sent from the MME to the VLR to indicate that, for example, paging could not be performed because 
the UE is marked as unreachable at the MME. Table 8.21.1 shows the content of the SGsAP-UE-UNREACHABLE 

message. 

Table 8.21 .1 : SGsAP-UE-UNREACHABLE message content 



Information element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
9.2 


M 


V 


1 


IMSI 


IMSI 
9.4.6 


M 


TLV 


6-10 


SGs cause 


SGs cause 
9.4.18 


M 


TLV 


3 



8.22 SGsAP-UPLINK-UNITDATA message 

This message is sent from the MME to the VLR to transparently convey a NAS message, from the UE, to the VLR. 
Table 8.22.1 shows the content of the SGsAP-UPLINK-UNITDATA message. 

Table 8.22.1 : SGsAP-UPLINK-UNITDATA message content 



Information element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
9.2 


M 


V 


1 


IMSI 


IMSI 
9.4.6 


M 


TLV 


6-10 


NAS message container 


NAS message container 
9.4.15 


M 


TLV 


4-253 



8.23 SGsAP-RELEASE-REQUEST message 

This message is sent by the VLR to the MME when the VLR determines that there are no more NAS messages to be 
exchanged between the VLR and the UE. Table 8.23.1 shows the content of the SGsAP-RELEASE-REQUEST 

message. 

Table 8.23.1 : SGsAP-RELEASE-REQUEST message content 



Information element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
9.2 


M 


V 


1 


IMSI 


IMSI 
9.4.6 


M 


TLV 


6-10 
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Information element coding 



9.1 



Overview 



This clause specifies the coding of the information elements used in by the SGs AP protocol. 

The spare bits in the coding of an information element shall be set to zero by the sender and shall be ignored by the 
receiver. 

All unassigned codes (whether omitted or explicitely Unassigned in the text) shall be treated as unknown (see clause 7). 



9.2 Message type 



Message type uniquely identifies the message being sent. It is a single octet information element, mandatory in all 
messages. Table 9.2.1 defines the value part of the Message type information element. 

Table 9.2.1 : Message type information element 



87654321 


Message type 


Reference 


00000000 


Unassigned: treated as an unknown Message type 


7 


00000001 


SGsAP-PAGING-REQUEST 


8.14 


00000010 


SGsAP-PAGING-REJEGT 


8.13 


0000001 1 

to 
0000010 1 


Unassigned: treated as an unl<nown Message type 


7 


00000110 


SGsAP-SERVIGE-REQUEST 


8.17 


000001 1 1 


SGsAP-DOWNLINK-UNITDATA 


8.4 


00001000 


SGsAP-UPLINK-UNITDATA 


8.22 


00001001 


SGsAP-LOCATION-UPDATE-REQUEST 


8.11 


000010 10 


SGsAP-LOCATION-UPDATE-AGGEPT 


8.9 


0000101 1 


SGsAP-LOGATION-UPDATE-REJEGT 


8.10 


00001100 


SGsAP-TMSI-REALLOGATION-GOMPLETE 


8.19 


00001101 


SGsAP-ALERT-REQUEST 


8.3 


00001110 


SGsAP-ALERT-AGK 


8.1 


00001111 


SGsAP-ALERT-REJEGT 


8.2 


00010000 


SGsAP-UE-ACTIVITY-INDICATION 


8.20 


00010001 


SGsAP-EPS-DETAGH-INDIGATION 


8.6 


000100 10 


SGsAP-EPS-DETAGH-ACK 


8.5 


00010011 


SGsAP-IMSI-DETAGH-INDIGATION 


8.8 


00010100 


SGsAP-IMSI-DETAGH-AGK 


8.7 


00010101 


SGsAP-RESET-INDIGATION 


8.16 


000101 10 


SGsAP-RESET-AGK 


8.15 


00010111 

to 
0001 100 1 


Unassigned: treated as an unknown Message type 


7 


00011010 


SGsAP-MM-INFORMATION-REQUEST 


8.12 


000110 11 


SGsAP-RELEASE-REQUEST 


8.23 


00011100 


Unassigned: treated as an unknown Message type 


7 


00011101 


SGsAP-STATUS 


8.18 


00011110 


Unassigned: treated as an unknown Message type 


7 


00011111 


SGsAP-UE-UNREAGHABLE 


8.21 
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9.3 



Information element identifiers 



The next list shows the coding of the information element identifiers used in the present document. Table 9.3.1 shows 
the values assigned for the information element identifiers. 

Table 9.3.1 : Information element identifier coding 



87654321 


Information element 


Reference 


0000000 1 


IMSI 


9.4.6 


000000 10 


VLR name 


9.4.22 


0000001 1 


TMSI 


9.4.20 


00000100 


Location area identifier 


9.4.11 


00000101 


Channel Needed 


9.4.23 


00000110 


eMLPP Priority 


9.4.24 


00000111 


TMSI status 


9.4.21 


00001000 


SGs cause 


9.4.18 


00001001 


IVIME name 


9.4.13 


00001010 


EPS location update type 


9.4.2 


000010 11 


Global CN-ld 


9.4.4 


00001110 


IVIobile identity 


9.4.14 


00001111 


Reject cause 


9.4.16 


00010000 


IIVISI detach from EPS service type 


9.4.7 


00010001 


IIVISI detach from non-EPS service type 


9.4.8 


00010101 


IMEISV 


9.4.5 


00010110 


NAS message container 


9.4.15 


00010111 


IVIM information 


9.4.12 


000110 11 


Erroneous message 


9.4.3 


00011100 


GLI 


9.4.1 


00011101 


LCS client identity 


9.4.9 


00011110 


LCS indicator 


9.4.10 


00011111 


SS code 


9.4.19 


00 100000 


Service indicator 


9.4.17 



9.4 



Information elements 



9.4.1 CLI 

This information element is used to represent calling line identification for the terminating call received in the CS 
domain. The CLI information element is coded as shown in figure 9.4.1.1. 





8 7 6 5 4 3 2 1 


Octet 1 


IE! 


Octet 2 


Length indicator 


Octet 3 

To 
Octet 14 


Octets 3 to 14 contain the value part of the Calling party BCD 
number information element defined in subclause 10.5.4.9 of 

3GPP TS 24.008 [8] (octets 3 to 14, i.e. not including 
3GPP TS 24.008 IE! and 3GPP TS 24.008 length indicator) 



Figure 9.4.1.1: Calling Line Identification information element 



9.4.2 EPS location upcJate type 



The purpose of the EPS location update type information element is to indicate to the VLR whether an IMSI attach or a 
normal location update has been performed by the UE. The EPS location update type information element is coded as 
shown in figure 9.4.2.1 and table 9.4.2.1. 
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8 7 6 5 4 3 2 


1 1 1 


Octet 1 


lEI 


Octet 2 


Length indicator 


Octet 3 


EPS location update type value 



Figure 9.4.2.1 : EPS location update type information element 
Table 9.4.2.1 : EPS location update type information element value part 



EPS location update type value (octet 3) 

Bits 
87654321 

00000000 Shall not be sent in this version of the protocol. If received, shall be treated as '0000001 0' 
1 IMSI attach 

1 Normal location update 

0000001 1 

to Shall not be sent in this version of the protocol. If received, shall be treated as '00000010' 

11111111 



Editor's note: Whether it is possible for the MME to discriminate between IMSI attach and normal location update 
in all cases, based on the information provided by the UE, is FES. 

9.4.3 Erroneous message 

See subclause 18.4.5 in 3GPP TS 29.018 [16]. 

9.4.4 Global CN-ld 

See subclause 18.4.27 in 3GPPTS 29.018 [16]. 

9.4.5 IMEISV 

See subclause 18.4.9 in 3GPP TS 29.018 [16]. 

9.4.6 IMSI 

See subclause 18.4.10 in 3GPP TS 29.018 [16]. 

9.4.7 IMSI (detach from EPS service type 

The IMSI detach from EPS service type information element indicates from MME to VLR the particular type of IMSI 
detach from EPS. The IMSI detach from EPS service type information element is coded as shown in figure 9.4.7.1 and 
table 9.4.7.1. 





8 7 6 5 4 3 2 


1 1 


Octet 1 


IE! 


Octet 2 


Length indicator 


Octet 3 


IMSI detach from EPS service type value 



Figure 9.4.7.1 : IMSI detach from EPS service type information element 
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Table 9.4.7.1 : IMS! detach from EPS service type information element value 



IMSI detach from EPS service type value (octet 3) 

Bits 
87654321 

00000000 Interpreted as reserved in this version of the protocol 
1 Network initiated IMSI detach from EPS service 

MS initiated IMSI detach from EPS service 

EPS services not allowed 



00000010 
0000001 1 
00000100 

to 
11111111 



Interpreted as reserved in this version of the protocol 



9.4.8 IMSI detach from non-EPS service type 

The IMSI detach from non-EPS service type information element indicates from MME to VLR the particular type of 
IMSI detach from non-EPS. The IMSI detach from non-EPS service type information element is coded as shown in 
figure 9.4.8.1 and table 9.4.8.1. 





8 7 6 5 4 3 2 


1 1 


Octet 1 


lEI 


Octet 2 


Length indicator 


Octet 3 


IMSI detach from non-EPS service type value 



Figure 9.4.8.1 : IMSI detach from non-EPS service type information element 



Table 9.4.8.1 : IMSI detach from non-EPS service type information element value 



IMSI detach from non-EPS service type value (octet 3) 
Bits 

87654321 

00000000 Interpreted as reserved in this version of the protocol 

1 Explicit UE initiated IMSI detach from non-EPS service 

Combined UE initiated IMSI detach from non-EPS service 
Implicit MME initiated IMSI detach from non-EPS 



00000010 
0000001 1 
00000100 

to 
11111111 



Interpreted as reserved in this version of the protocol 



9.4.9 LCS client identity 

The LCS client identity information element is a compound parameter and comprises information related to the client of 
a LCS request. The LCS client identity information element is coded as shown in figure 9.4.9.1. 





8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2 


Length indicator 


Octet 3 

to 
Octet n 


The coding of the LCS client identity value is according to LCS- 
ClientlD as specified in subclause 17.7.13 of 3GPP TS 29.002 [15] 



Figure 9.4.9.1 : LCS client identity information element 
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9.4.10 LCS indicator 

The LCS indicator information element indicates that the origin of the message is due to a LCS request and the type of 
this request. The LCS indicator information element is coded as shown in figure 9.4.10.1 and table 9.4.10.1. 





8 


7 


6 5 4 3 


2 


1 


Octet 1 


lEI 


Octet 2 


Length indicator 


Octet 3 


LCS indicator value 



Figure 9.4.10.1 : LCS indicator information element 
Table 9.4.10.1 : LCS indicator value 



LCS indicator 




Bits 




87654321 




00000000 


Normal, unspecified in this version of the protocol. 


00000001 


MT-LR 


000000 10 




to 


Normal, unspecified in this version of the protocol 


11111111 





9.4.1 1 Location area identifier 

This element uniquely identifies one Location Area. The Location area identifier information element is coded as shown 
in figure 9.4.11.1. 





8 7 6 5 4 3 2 1 


Octet 1 


IE! 


Octet 2 


Length Indicator 


Octet 3 
Octer 7 


Octets 3 to 7 contain the value part of the Location area 

identification information element defined in 3GPP TS 24.008 [8] 

(starting with octet 2, i.e. not including 3GPP TS 24.008 lEI) 



Figure 9.4.11.1 : Location area identifier information element 

9.4.12 MM information 

The MM information information element is a TLV information element that encapsulates the user information that the 
MME forwards to the UE. For the coding see subclause 18.4.16 in 3GPP TS 29.018 [16]. 

9.4.13 MME name 

The MME name information element specifies the MME name and is coded as shown in figure 9.4.13.1. Octets 3 
through n contain the name in the form of a fully qualified domain name (FQDN) as specified in 3GPP TS 23.003 [3]. 
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8 7 6 5 4 3 2 


1 


Octet 1 


lEI 


Octet 2 


Length Indicator 


Octet 3 
Octet n 


MME name (leftmost character of FQDN) 
MME name (rightmost character of FQDN) 



Figure 9.4.13.1 : MME name information element 

9.4.14 Mobile identity 

See subclause 18.4.17 in 3GPPTS 29.018 [16]. 

9.4.15 NAS message container 

This information element is used to encapsulate the SMS messages transferred between the VLR and the MME. The 
NAS message container information element is coded as shown in figure 9.4.15.1. 





8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2 


Length indicator 


Octet 3 

to 

Octet 253 


Octets 3 to 253 contain the SMS message (i.e. CP-DATA, CP-ACK 

or CP-ERROR) as defined in subclause 7.2 of 

3GPPTS 24.011 [10] 



Figure 9.4.15.1 : NAS message container information element 

9.4.16 Reject cause 

See subclause 18.4.21 in 3GPP TS 29.018 [16]. 

9.4.17 Service indicator 

This information element indicates the type of the CS service (e.g. voice call, Short Message Service). CS call indicator 
is used for all the CS services except the SMS. The Service indicator information element is coded as shown in 
figure 9.4.17.1 and table 9.4.17.1. 
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6 1 5 1 4 1 3 
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1 1 


Octet 1 


IE! 


Octet 2 


Length indicator 


Octet 3 


Service indicator value 



Figure 9.4.17.1 : Service indicator information element 
Table 9.4.17.1 : Service indicator value 



Service indicator 

Bits 
87654321 

00000000 Shall not be sent in this version of the protocol. If received, shall be treated as '00000001 ' 

00000001 CS call indicator 

1 SMS indicator 

0000001 1 

to Shall not be sent in this version of the protocol. If received, shall be treated as '00000001 ' 

11111111 
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9.4.18 SGs cause 

The purpose of the SGs cause information element is to indicate an error to the receiving entity. This could be a 
protocol data error, to indicate to the VLR the reason why a paging procedure could not be performed or to indicate to 
the VLR that the mobile terminating CS fallback call has been rejected by the user. The SGs cause information element 
is coded as shown in figure 9.4.18.1 and table 9.4.18.1. 
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7 
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1 5 1 4 1 


3 


2 


1 1 


Octet 1 


lEI 


Octet 2 


Length indicator 


Octet 3 


SGs cause value 



Figure 9.4.18.1 : SGs cause information element 
Table 9.4.18.1 : SGs cause information element value part 



SGs cause value 

Bits 
87654321 
00000000 

0000000 1 
00000010 

0000001 1 
00000100 
00000101 
000001 10 
00000111 
00001000 
00001001 
00001010 
000010 11 
00001100 
00001101 
00001110 

to 

11111111 



(octet 3) 



Normal, unspecified in this version of the protocol. 

IMS! detached for EPS services 

IIVISI detached for EPS and non-EPS services 

IIVISI unknown 

IMS! detached for non-EPS services 

IMS! implicitly detached for non-EPS services 

UE unreachable 

Message not compatible with the protocol state 

Missing mandatory information element 

Invalid mandatory information 

Conditional information element error 

Semantically incorrect message 

Message unknown 

Mobile terminating CS fallback call rejected by the user 

Normal, unspecified in this version of the protocol 



NOTE: "Normal, unspecified" has the same meaning than in 
3GPP TS 24.008 [8], informative Annex H (UMTS specific cause values for 
call control). It is used to report a normal event, and should not be interpreted 
as syntactically incorrect nor unknown if received. 



9.4.19 SScode 

The SS code information element is used to represent the code identifying a single supplementary service, a group of 
supplementary services, or all supplementary services. The SS code information element is coded as shown in 
figure 9.4.19.1. 





8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2 


Length indicator 


Octet 3 


The coding of the SS code value is according to SS-Code as 
specified in subclause 17.7.5 of 3GPP TS 29.002 [15] 



Figure 9.4.19.1 : SS code information element 



9.4.20 TMSI 

See subclause 18.4.23 in 3GPP TS 29.018 [16]. 
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9.4.21 TMSI status 

See subclause 18.4.24 in 3GPP TS 29.018 [16]. 

9.4.22 VLR name 

The VLR name information element specifies the VLR name and is coded as shown in figure 9.4.22.1. Octets 3 through 
n contain the VLR name in the form of a fully qualified domain name (FQDN) as specified in IETF RFC 1035 [21]. 
The VLR name is locally configured in the MME. 





8 7 6 5 4 3 2 


1 1 


Octet 1 


lEI 


Octet 2 


Length Indicator 


Octet 3 
Octet n 


VLR name (leftmost character of FQDN) 
VLR name (rightmost character of FQDN) 



Figure 9.4.22.1 : VLR name information element 



9.4.23 Channel needed 

See subclause 18.4.2 in 3GPP TS 29.018 [16]. 

9.4.24 eMLPP priority 

See subclause 18.4.4 in 3GPP TS 29.018 [16]. 
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1 List of system variables 
10.1 Timers 

This subclause lists the management timers specified for the operation of the SGsAP protocol. All the implementation 
shall support the range of values specified in table 10.1.1 or table 10.1.2 as appropriate. The specific value of the timers 
is under the control of the operator. 

Table 10.1.1: Management timers - MME side 



Timer 
name 


Default 
value 


Timer 
range 


Granularity 


Notes 


Relation to other timers 


Ts6-1 




10 s to 90s 


1 s 


Guards the Location Update 
procedure. 


It is expected to take a value greater 
than 2 times the maximum transmission 
time in the SGs interface, plus the 
supervision timer of the Update 
Location procedure (as defined in 
3GPPTS 29.002 [15]) 


Ts8 


4s 


1 s to 30 s 


1 s 


Guards the Explicit IIVISI 
detach from EPS services 
procedure. 


None. 


Ts9 


4s 


1-30 s 


1 s 


Guards the Explicit IMSI 
detach from non-EPS 
services procedure. 


None. 


Ts10 


4s 


1-30 s 


1 s 


Guards the Implicit IMSI 
detach from non-EPS 
services procedure. 


None. 


Ts12-1 




8- 

60x384-^8 s 


1 min 


Controls the resetting of the 
'IVIME-Reset' variable. 


It is expected to take a value greater 
than the longest periodic tracking area 
update timer running on the MME, plus 
the transmission delay on the radio 
interface. 


Ts12-2 


4s 


1-120S 


1 s 


Guards the MME reset 
procedure. There is one 
Ts12-2 timer per VLB for 
which the MME has a SGs 
association. 


None. 


NOTE: The Default value is the recommended value. 



Table 10.1.2: Management timers - VLR side 



Timer 
name 


Default 
value 


Timer 
range 


Granularity 


Notes 


Relation to other timers 


Ts5 




2 s to 20 s 


100 ms 


Guards the Paging 
procedure at the VLR. 


Value is correlated to paging cycle. The 
default is set according to maximum 
paging cycle supported by the MME 
(operator choice) as defined in 
3GPPTS 36.331 [19]. 


Ts6-2 


40 s 


5 s to 60 s 


1 s 


Guards the IMS! 
reallocation procedure. 


It is expected to take a value greater 
than 2 times the maximum transmission 
time in the SGs interface, plus 4 times 
T3450 (as defined in 
3GPPTS 24.301 [14]) 


Ts7 


4s 


1 s to 30 s 


1 s 


Guards the Non-EPS alert 
procedure. 


None. 


Tsll 


4s 


1-120S 


1 s 


Guards the VLR reset 
procedure. There is one 
Ts1 1 timer per MME for 
which the VLR has a SGs 
association. 


None. 


NOTE: The Default value is the recommended value. 
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10.2 Retry counters 



This subclause lists the management retry counters specified for the operation of the SGsAP protocol. The values in 
table 10.2.1 and table 10.2.2 are recommended values. 

Table 10.2.1 : Management retry counters - VLR side 



Retry counter name 


Retry value 


Ns7 


2 


Ns11 


2 



Table 10.2.2: Management retry counters - MME side 



Retry counter name 


Retry value 


Ns8 


2 


Ns9 


2 


Ns10 


2 


Ns12 


2 
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